User terminals, for example self-service terminals such as ATMs, are very widely used for a variety of purposes. Large financial institutions, such as banks, typically maintain networks of many thousands of ATMs. The ATMs in a particular network, or maintained by a particular organisation, may include a variety of different types or models and a range of different ages and functionalities, are often produced by different manufacturers, and may have different software or operating systems installed.
The diversity of ATMs makes maintenance of ATMs and the production of new software for such ATMs difficult. For example, it may be necessary to produce many different versions of a new ATM application to ensure that it is compatible with each of the different types of ATM in a network. Such difficulties are becoming particularly acute as there has been a move towards providing additional functions or services via ATMs, for example mobile phone top-up services, which require the installation of additional, often sophisticated, applications.
The CEN/XFS standard architecture was developed in order to ensure software compatibility across different ATMs. The CEN/XFS architecture provides a common API layer, also referred to as a service provide layer, that comprises API or service provider modules that provide for communication with and control of hardware devices (for example a keypad, an audio output, or a receipt printer) included in the ATM.
Each hardware manufacture provides service provider modules that include XFS-compliant software, for example dynamically linked libraries (DLLs) that enable communication with and control of hardware devices produced by that manufacturer. Each service provider module provides for a minimum level of commands for associated hardware devices as defined by the CEN/XFS standard.
In operation XFS-compliant applications in the application layer of the ATM send XFS-compliant commands to the appropriate service provider modules in the service provider layer, which can convert the commands to the appropriate hardware-specific format if necessary, and pass the commands on to the appropriate hardware device driver. Similarly, data can be received from hardware devices by the service provider modules and forwarded to the appropriate application in the application in the XFS-compliant format. By using standard XFS commands an application can, in principle, communicate with any installed hardware device if an XFS service provider module is provided for the hardware device.
Each ATM can include service provider modules for different hardware manufacturers (for example NCR, Diebold and Wincor Nixdorf) and hardware devices. The service provider modules that are to be used in a particular ATM are defined by keys stored in a registry of the ATM processing system. The ATM can include an XFS management layer in addition to the service provider layer, which directs commands or other messages to the appropriate service provider module based on the registry keys.
Although the CEN/XFS architecture improves the compatibility of ATM software across different hardware platforms, it is directed to only standard ATM functions. More sophisticated applications directed to more complex ATM functions are not supported under the XFS architecture. Furthermore, the CEN/XFS architecture does not provide for simultaneous access to hardware devices by more than one application, and even serial access to the same hardware device by different applications can cause system crashes. Such system crashes may be avoided by synchronisation of the applications at the application layer, but that is not straightforward, requires modification to the applications and does not allow for addition or replacement of applications.
It is an aim of the present invention to provide an improved, or at least alternative, processing system and method for a user terminal.